Abstract - Introduction to Fast Function Points

In one way or another all stakeholders, project managers, end users, and executives must work with software size metrics, however, many organizations do not have the patience or budget to fully implement IFPUG function point counting techniques. Fast Function Points were developed by the Cost Xpert Group, as an extension of work by Software Productivity Research, Inc. (SPR), to support approximate function point estimates with a minimal of effort and training. Fast Function Points supplement rather than replace IFPUG function points, but are particularly useful at early stages of the software lifecycle. This talk introduces Fast Function Points, describes their proper use, and presents case studies. The Need for Shortcuts Function Point counting, as originally introduced by Albrecht in 1979, was aimed at a relatively homogenous set of applications and way of building software. Screens were CICS “green screens” or something similar, sequential records on magnetic tapes were used for input, output, temporary storage, and so on. The function point counting methodology was easy, and intuitively understood by managers and end users with little or no computer software background, basically involving counting of inputs, outputs, inquiries, and master files and multiplying each of these values times a fixed multiplier. Over time, the function point counting methodology became increasingly complex to support software that was increasingly complex. Files were broken down by internal files versus interface files. Each element that was counted received an individual complexity adjustment. Project level complexity adjustments were used to make global adjustments to the function point totals. The end result was a counting methodology documented in ISO/IEC 20926 that yields precise answers for a wide variety of projects, but which suffers from the following disadvantages: • Learning the counting methodology has gone from a few hours of explanation to a class lasting weeks combined with formal certification; • The methodology has gone from something readily understood by end users and easily used by end users and project managers for scope control during requirement definition, to something that end users and project managers understand only at a conceptual level; • Function point counts have gone from something accomplished in a number of hours from a requirement specification or existing application to something taking weeks or sometimes months of skilled labor; • Revisions to function point counts throughout the requirement and design phase were easy and simple and they could be accomplished in near real-time, but now updates to function point counts are typically accomplished only at major milestones because of the effort involved; and • Function points are often used as inputs to cost estimating tools, however, if the project level complexity adjustments are made during the function point counts these may overlap with similar effort adjustments made within the estimating tool. None of this is meant to discourage organizations from making formal function point counts per ISO/IEC 20926 and using certified function point counting specialists. This remains the most reliable method of ensuring an accurate, consistent function point count. However, we believe that there is a place in the software development world (and lifecycle) for informal approaches that will approximate the function point values obtained through more formal approaches.